<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Concept: Architectural Mechanism</title>
<meta name="uma.type" content="Concept">
<meta name="uma.name" content="arch_mechanism">
<meta name="uma.presentationName" content="Architectural Mechanism">
<meta name="element_type" content="concept">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="_mzxI0A4LEduibvKwrGxWxA"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Concept: Architectural Mechanism</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/concept.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">Architectural Mechanisms are common solutions to common problems that can be used during development to minimize complexity.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/analysis_mechanism_8369C159.html" guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_arch.base/guidances/checklists/architecture_notebook_BC815A4B.html" guid="_17PYUNd6EdmIm-bsRSNCgw">Architecture Notebook</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/tasks/design_solution_A97CE9EA.html" guid="_0fshwMlgEdmt3adZL5Dmdw">Design the Solution</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_arch.base/tasks/outline_the_arch_FF123A81.html" guid="_0f-1oMlgEdmt3adZL5Dmdw">Outline the Architecture</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_arch.base/tasks/refine_the_arch_7723A69E.html" guid="_0gRJgMlgEdmt3adZL5Dmdw">Refine the Architecture</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html" guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><h3>
    What are Architectural Mechanisms?
</h3>
<p>
    Architectural Mechanisms are common solutions to common problems that can be used during development to minimize
    complexity.&nbsp; They represent key technical concepts that&nbsp;will be standardized across the solution.&nbsp;
    Architecture mechanisms facilitate the evolution of architecturally significant aspects of the system. They allow the
    team to maintain a cohesive architecture whilst enabling implementation details to be deferred until they really need
    to be made.
</p>
<p>
    Architectural Mechanisms are&nbsp;used to satisfy architecturally significant requirements. Usually those are
    non-functional requirements such as performance and security issues.&nbsp;When fully described, Architectural
    Mechanisms show patterns of structure and behavior in the software. They&nbsp;form the basis of&nbsp;common
    software&nbsp;that will be&nbsp;consistently applied&nbsp;across the product being developed. They also form the basis
    for standardizing the way that the software works; therefore, they are an important element of the overall software
    architecture. The definition of architecture mechanisms also enable decisions on whether existing software components
    can be leveraged to provide the required behavior; or whether new software should be bought or built.
</p>
<p>
    The value in defining architecture mechanisms is that they:
</p>
<ol>
    <li>
        Explicitly call out&nbsp;aspects of the solution mechanics that are common across the system. This helps you plan.
    </li>
    <li>
        Put down markers for the developers to build those aspects of the system once and then re-use them. This reduces
        the workload.
    </li>
    <li>
        Promote the development of a consistent set of services. This makes the system easier to maintain.
    </li>
</ol>
<p>
    An&nbsp;Architectural Mechanism can have three states: Analysis, Design and Implementation.&nbsp;These
    categories&nbsp;reflect the maturity of the mechanism's description. The state changes as successive levels of detail
    are uncovered during when you refine <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html" guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>&nbsp;into working software. The categories
    are summarized in the table that follows.
</p><strong>States of an Architectural Mechanism</strong> 
<table style="WIDTH: 806px; HEIGHT: 228px" cellspacing="0" cellpadding="2" width="806" summary="Types of Architectural Mechanism" border="1">
    <tbody valign="top">
        <tr>
            <th scope="col">
                State
            </th>
            <th scope="col">
                Description
            </th>
        </tr>
        <tr>
            <td>
                Analysis
            </td>
            <td>
                <p>
                    A conceptual solution to a common technical problem. For example,&nbsp;persistence is an abstract
                    solution to the common requirement to store data. The purpose of this category is simply to identify
                    the need for an Architectural Mechanism to be designed and implemented; and capture basic attributes
                    for that mechanism.
                </p>
            </td>
        </tr>
        <tr>
            <td>
                Design
            </td>
            <td>
                <p>
                    A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of
                    this category is to guide precise product or technology selection.
                </p>
            </td>
        </tr>
        <tr>
            <td>
                Implementation
            </td>
            <td>
                <p>
                    A further refinement from a design mechanism into a specification for the software. This can be
                    presented as a design pattern or example code.
                </p>
            </td>
        </tr>
    </tbody>
</table><br />
<p>
    For more information on these different types of mechanisms, see the attached concepts.
</p>
<p>
    Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation
    mechanisms.&nbsp;These are synonyms and merely represent the architecture mechanisms in different states of
    development. The transition from one state to another&nbsp;can often be obvious or intuitive. Therefore, it can be
    achieved in a matter of seconds. It can also require more considered analysis and design, thus take longer.&nbsp;The
    important point here is that these categories of mechanisms apply to the same concept in different states. The only
    difference between them is one of refinement or detail.
</p>
<p>
    The following diagram illustrates the transition of Architectural Mechanisms from one state to another.
</p>
<p>
    <strong>State Machine for Architectural Mechanisms</strong>
</p>
<p>
    <img style="WIDTH: 876px; HEIGHT: 115px" height="113" alt="Architectural Mechanism States"     src="./../../../core.tech.common.extend_supp/guidances/concepts/./resources/ArchMechStates.JPG" width="600" />&nbsp;
</p>
<h3>
    What Information Should be Captured for Architectural Mechanisms?
</h3>
<p>
    The information captured for each architectural mechanism category/state is different (though the information can be
    seen as refinements of each other):
</p>
<ul>
    <li>
        <strong>Analysis Mechanisms</strong>, which give the mechanism a name, brief description and some basic
        attributes&nbsp;derived from&nbsp;the project requirements
    </li>
    <li>
        <strong>Design Mechanisms</strong>, which are more concrete and assume some details of the implementation
        environment
    </li>
    <li>
        <strong>Implementation Mechanisms</strong>, which specify the&nbsp;exact implementation of&nbsp;each mechanism
    </li>
</ul>
<p>
    When&nbsp;a mechanism is&nbsp;initially identified, it can be considered a marker that says to the team, "We are going
    to handle this aspect of the system in a standard way. We'll figure out the details later." As the project proceeds,
    the architectural mechanisms are gradually refined until they become part of the software.
</p>
<h4>
    Analysis Mechanisms
</h4>
<p>
    Analysis mechanisms&nbsp;are the initial state for an architectural mechanism. They are identified early in the project
    and represent&nbsp;bookmarks for future software development. They allow the&nbsp;team to focus on understanding the
    requirements without getting distracted by the specifics of a complex implementation. Analysis mechanisms are
    discovered by surveying the requirements and looking for recurrent technical concepts.&nbsp;Security, persistence and
    legacy interface are some examples of these. In effect, the analysis mechanism is where the requirements that
    describe&nbsp;architecturally significant topics&nbsp;are collated and brought&nbsp;together in a single list. This
    makes them easier to manage.
</p>
<p>
    Analysis mechanisms are described in simple terms:
</p>
<ul>
    <li>
        <strong>Name:</strong> Identifies the mechanism.
    </li>
    <li>
        <strong>Basic attributes:</strong> Define the requirements of the mechanism. These attributes can vary depending
        upon the mechanism being analyzed. Refer to <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html" guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a>&nbsp;for more guidance.
    </li>
</ul>
<p>
    Once the list of analysis mechanisms has been defined it can be prioritized and the mechanisms refined in line
    with&nbsp;iteration&nbsp;objectives. It is not necessary to develop the entire set of architecture mechanisms into
    working software in a single pass. It is often more sensible to develop only those mechanisms required to support the
    functionality to be delivered in the current iteration.
</p>
<h4>
    Design Mechanisms
</h4>
<p>
    Design mechanisms&nbsp;represent decisions about the concrete technologies that are going to be used to&nbsp;develop
    architectural mechanisms. For example, the decision to use an RDBMS for persistence. It's often no more complicated
    than that (though of course, the effort involved in making the decision can sometimes be quite complex).
</p>
<p>
    The decision on when to refine an architectural mechanism from an analysis state to a design state is largely
    arbitrary. Often there will be constraints on the project that&nbsp;force the decision on some of these issues. For
    example, there may be a corporate standard for databases which mean that the decision&nbsp;for the&nbsp;persistence
    mechanism can be made on day 1 of the project.
</p>
<p>
    On other occasions the decision may point to products that the project team has not yet acquired.&nbsp;If so,&nbsp;the
    decision needs to be made in time to enable the required products to be made available to the team.
</p>
<p>
    It can often be useful to develop some prototype code to prove that these decisions are sound. The <a class="elementLink" href="./../../../core.default.role_def.base/roles/architect_E7A12309.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> should be confident that the technologies being selected are able to
    fulfill the requirements. The attributes captured against the corresponding analysis mechanisms should be used as
    criteria to prove the validity of the decisions.
</p>
<h4>
    Implementation Mechanism
</h4>
<p>
    An implementation mechanism&nbsp;specifies the actual implementation for the architectural mechanism (hence the
    name).&nbsp;It can be modeled as a design pattern or presented as&nbsp;example code.
</p>
<p>
    The best time to&nbsp;produce the&nbsp;implementation mechanism is usually when the first piece of functionality that
    needs it is scheduled for development. Architects and developers work together to develop this.
</p>
<p>
    For examples of the kinds of information that you might capture for a mechanism, see <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html" guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a>.
</p></td>
</tr>
</table>
</div>
<div class="sectionHeading">More Information</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Concepts</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/analysis_mechanism_8369C159.html" guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html" guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/design_mechanism_CE197B4E.html" guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/implementation_mechanism_C92E670B.html" guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>
</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Examples</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html" guid="_eQ_s8Om5Edupia_tZIXEqg">Architectural Mechanism Attributes</a>
</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Guidelines</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/guidelines/example_design_mechanisms_7762C0FB.html" guid="_4k_Hsg4LEduibvKwrGxWxA">Example: Design Mechanisms</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/guidelines/identify_common_architectural_mechanisms_203A2A5C.html" guid="_M2lNcJo7Ed2Jdb_Cbj3yAA">Identify Common Architectural Mechanisms</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright"><p> This program and the accompanying materials are made available under the<br />
  <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse 
  Public License V1.0</a>, which accompanies this distribution. </p><p/><p> <a class="elementLink" href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/openup_copyright_C3031062.html" guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a></p></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
